Amazon Elasticsearch Serviceをログの収集・参照に使うために最低限必要なこと

モバイルアプリサービス部＠モバイルバックエンドチームの五十嵐です。

ログデータの収集・参照のためにAmazon Elasticsearch Service + Kibanaを利用しました。 実際にやってみて分かった設計上のポイントをまとめてみます。

データ量

• ストレージが利用するデータ量は、登録するJSONのデータ量だけでなくIndexによるメタ情報が付加されます。データ量を求めるには、実際のデータを登録してみて1件あたりのデータ量を測定するのが確実です。
• Amazon Elasticsearch Serviceの場合は、ストレージ（EBSボリューム）のサイズを後から変更できるため、シビアに考えなくても良いと思います。
• データ量を抑えるには、不要なIndexを作らないようにする方法もあります。例えば、検索するFieldが限られているのであれば、メタフィールドの _all （全てのフィールドのインデックス）を作らないようにするなど。

_all フィールドを作らないようにするmappingの設定例。

{
"template" : "sample-*",
"mappings" : {
"_default_" : {
"_all" : { "enabled" : false }
}
}
}

データのローテーション

• ログデータを収集する場合、古くなったデータをどのようにローテート（削除）するかを考える必要があると思います。
• 一般的にログデータは一定期間ごとにIndexを分けて登録します。Indexを日単位や月単位にしておくことで、古くなったIndexをIndexごと削除します。
• もしくは、Indexは1つだけで、IndexのMappingにDocumentのTTLを設定しておくことで、TTLが切れたDocumentを自動的に削除する方法もあります。
• データ量が少ないうちはTTLでも良いと思いますが、それなりに負荷がかかるのでデータ量が多くなってきたらIndexを分けるようにすると良いと思います。

TTLを設定する設定例。

{
"template" : "sample-*",
"mappings" : {
"_default_" : {
"_ttl" : {
"enabled" : true,
"default" : "1"
}
}
}
}

IndexTemplate

• Indexの設定はIndexTemplateにしておくと、Indexが作成された時にIndexTemplateの設定が反映されるので設定漏れがなくて良いです。ただし、IndexTemplateを更新しても既に存在するIndexには適応されないので注意が必要です。
• IndexTemplateは、設定を適応するIndexをワイルドカードで指定できるので、共通設定用のTemplateを作ることもできます。ただしIndexやmappingの中にはシステムが利用するものもありますので、"*"で全てのIndexを対象にするのは避けましょう。
• Hash値やメールアドレスなど、文字列区切りでインデックスされたくない項目には "index" : "not_analyzed" を設定します。

{
"template" : "sample-*",
"mappings" : {
"_default_" : {
"properties" : {
"email" : {
"type" : "string",
"index" : "not_analyzed"
}
}
}
}
}

タイムゾーン

• Kibana4では、ブラウザが持つタイムゾーンの情報を元に自動的にタイムゾーンを変換して表示してくれます。
• タイムゾーンなしのフォーマットで登録するとUTCとして扱われますので、UTC時間で登録するか、JSTで登録する場合はタイムゾーンありのtimeフォーマット（ISO8601形式など）にする必要があります。

まとめ

Amazon Elasticsearch Serviceでログデータを扱う上で最低限必要なことをまとめてみました。あとはデータの使い方次第でデータやIndexを設計していくことになると思います。

Amazon Elasticsearch Serviceはマネージドサービスになっており構築やメンテナンスの手間がかからずとても便利です。便利な反面、制約もあるのですが、ログデータを扱う程度なら十分という感じを受けました。Elasticsearchの導入をこれから考えている方は是非活用してみてください！